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ABSTRACT 


The  objective  of  this  project  was  to  evaluate  and  make  recommendations  for 
improving  existing  procedures  for  the  Joint  National  Test  Facility  (JNTF)  engineering 
process.  The  research  focused  on  the  JNTF  project  managers  process  for  requirements 
refinement.  Background  was  provided  by  a  review  of  the  JNTF  DIRECTIVE  NO.  4200, 
which  outlines  the  processing  of  JNTF  Task  Orders.  Some  parts  of  the  JNTF  Systems 
Engineering  Management  Plan  (SEMP)  were  also  reviewed.  Data  were  provided  by 
interviews  of  seven  out  of  a  possible  twenty  JNTF  project  managers.  The  data  collected 
from  the  project  managers  is  the  basis  for  the  recommendations  made.  The  survey 
information  is  organized  using  a  three  P  analysis.  The  three  Ps  are  Preparation,  Payoff, 
and  Performance.  The  principal  recommendations  for  improvement  are  listed  below: 

•  The  primary  recommendation  is  that  the  JNTF  develop  and  implement  a 
Project  Manager  Certification  Program.  Part  of  this  certification  program 
should  include  attendance  by  all  project  managers  at  the  Defense  Systems 
Management  College  (DSMC)  acquisition  101  or  an  equivalent  course. 

•  The  JNTF  SEMP  needs  to  be  evaluated  for  its  usefulness  and  then  appropriate 
action  should  be  taken  to  revise  the  SEMP  continually  or  discontinue  use  of 
the  SEMP. 

•  Project  manager  communication  needs  to  be  improved  to  reduce  redundancy 
at  the  JNTF. 

•  The  Requirements  Correlation  Matrix  should  be  used  to  track  the  progression 
of  requirements  throughout  a  projects  lifecycle. 

•  All  integral  personnel  need  to  be  involved  at  every  critical  step  to  make  the 
process  more  efficient. 
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Background 

The  objective  of  this  project  was  to  evaluate  and  make  recommendations  for 
improving  existing  procedures  for  the  Joint  National  Test  Facility  (JNTF)  engineering 
process.  The  area  affected  is  the  JNTF  with  emphasis  on  project  manager  (PM)  actions 
and  tasks  for  requirements  processing.  The  JNTF  suffers  from  reluctance  to  adhere  to 
documented  engineering  processes  by  the  government  project  leads  (project  managers). 
Some  of  the  project  managers  interviewed  managed:  War  Game  2000,  Studies  and 
Analysis,  Technology  Insertion,  Simulation  Support  Center,  Exercise  Support,  and 
Software  Engineering. 

Introduction 

The  tasks  required  for  this  research  project  were: 

1 .  Evaluate  present  engineering  processes  used  by  government  project 
managers  with  associated  metrics  (specifically  the  method  to  go  from 
customer  idea  to  requirements). 

2.  Provide  improvement  suggestions  to  better  meet  the  needs  of  the  government. 

3.  Provide  a  method  to  track  requirements  throughout  a  projects  lifecycle. 

Task  number  one  was  done  by  reviewing  the  JNTF  Directive  number  4200,  reviewing 
parts  of  the  JNTF  Systems  Engineering  Management  Plan,  and  interviewing  some  of  the 
JNTF  project  managers.  Task  number  two,  providing  suggestions  for  improvement,  is 
done  throughout  this  paper  and  summed  up  in  the  conclusions.  I  will  make  a 
recommendation  for  task  number  three  in  the  performance  section  of  this  paper. 

3  P  Analysis 

The  three  P’s  are  Preparation,  Performance,  and  Payoff.  The  following  diagram 
shows  the  interaction  between  the  three  P’s. 
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Preparation  feeds  into  performance,  and  performance  feeds  into  payoff.  Payoff 
also  feeds  into  performance,  because  knowing  your  payoff  can  improve  your 
performance.  Preparation  includes;  project  manager  training  and  certification, 
references  available  to  the  project  managers,  and  each  project  manager’s  personal 
background.  Payoff  is  the  incentive  to  work  hard  and  includes  job  satisfaction, 
recognition  for  good  work,  and  a  good  reputation  for  the  JNTF.  Performance  is  a 
measure  of  the  project  manager’s  effort  and  is  based  on  meeting  the  customer’s 
requirements.  A  survey  was  used  to  collect  information  from  seven  of  the  twenty  project 
managers  at  the  JNTF.  Note:  In  one  of  the  PM  interviews  I  did  not  get  to  three  of  the 
questions.  The  survey  results  constitute  a  majority  of  this  paper  and  lead  to  the  solutions 
recommended.  I  used  the  3  P  analysis  to  organize  the  results  of  the  survey.  I  have 
underlined  each  of  the  survey  questions  and  included  them  under  one  of  the  three  P’s. 
After  some  of  the  questions  recommendations  for  improvement  are  given. 

PREPARATION 

I  am  starting  the  preparation  section  with  a  discussion  of  the  two  JNTF  documents 
I  reviewed  to  gain  an  understanding  of  the  processes  that  are  used  at  the  JNTF.  I 
reviewed  the  JNTF  DIRECTIVE  NO.  4200,  which  outlines  the  processing  of  Joint 
National  Test  Facility  Task  Orders.  A  task  order  is  “a  document  that  identifies  the 
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specific  tasks,  products,  schedules,  and  technical  approach  which  is  jointly  prepared  by 
the  Government  and  the  Contractors.”  [1] 

I  also  reviewed  parts  of  the  JNTF  Systems  Engineering  Management  Plan 
(SEMP)  Contract  Data  Requirements  List  (CDRL)  A078-002B  from  2  April  1996.  The 
JNTF  “. .  .(SEMP)  (CDRL  A078)  defines  the  engineering  process  used  at  the  JNTF.  It 
describes  the  roles  and  responsibilities  for  coordinating  and  integrating  JNTF  efforts  in 
requirements  definition,  design,  development,  test,  logistics,  operations,  and  maintenance 
to  attain  engineering  goals  of  performance,  cost,  and  schedule  in  support  of  JNTF 
customer  needs.”  [2]  Another  quote  that  further  describes  the  SEMP  is,  “The  SEMP 
defines  the  processes,  procedures,  engineering  techniques,  technical  disciplines,  and 
organizational  interfaces  utilized  by  the  Government  and  contractors  to  develop  and 
support  the  evolving  requirements  of  existing  and  new  programs  at  the  JNTF.”  [2]  The 
Table  of  Contents  from  the  SEMP  can  be  found  in  appendix  A. 

Do  you  feel  that  you  were  properly  trained  to  be  a  project  manager?  If  not,  what  type  of 
training  should  be  implemented? 

The  majority  of  the  project  managers  interviewed  felt  that  they  were  not  properly 
trained  to  be  project  managers.  Currently  the  JNTF  is  offering  monthly  project  manager 
training  on  subjects  including  finance,  task  orders,  and  award  fee  assessment.  The 
courses  are  on  tape  and  the  instructors  are  JNTF  employees  who  are  the  experts  from  the 
particular  area  at  the  JNTF.  There  are  currently  10  tapes  and  new  topics  can  be  added  as 
needed.  A  copy  of  the  spreadsheet  that  outlines  the  courses  offered  is  included  in 
appendix  B.  The  spreadsheet  was  e-mailed  to  me  by  Mr.  Fred  Ehlers  from  the  JNTF. 
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This  monthly  training  does  not  go  over  the  details  of  working  with  operations  or 


engineering. 

The  Joint  National  Test  Facility’s  Organization  and  Functions  Manual  from  12 
Jan  1998,  has  a  section  on  page  9  about  a  Plans  and  Requirements  (CIX)  group.  One  of 
the  duties  for  the  CIX  group  states,  “Manage  JNTF  Project  Management  Program 
(Project  Manager  Checklist,  Handbook,  and  Training  Program).  Manage  the  Project 
Manager  Certification  Program.”  The  CIX  group  is  currently  filled  by  two  JNTF 
Advisory  and  Assistance  Services  (NAAS)  contractors.  I  posed  questions  about  these 
duties  of  the  CIX  group  to  Mr.  Vic  McMillen,  who  works  at  the  JNTF  and  is  part  of  the 
Requirements  Definition  Working  Group.  I  found  that  the  Project  Manager  Checklist 
from  May  7,  1996  is  currently  being  revised.  The  Project  Manager  Handbook  is  not 
currently  being  developed.  The  Project  Manager  Training  Program  is,  “currently  a  part 
of  the  Contracting  Officer  Representative  (COR)  training  which  all  project  managers 
have  to  attend.”  [3]  “The  COR  is  appointed  by  the  Procuring  Contracting  Officer  (PCO) 
and  is  the  senior  government  representative  who,  together  with  the  PCO,  is  responsible 
for  surveillance  and  assessment  of  contractor  performance  on  the  contract.”  [1]  The  PCO 
is  responsible  for  contract  actions.  [1]  The  Project  Manager  Certification  Program  is, 
“Not  currently  under  development  and  will  have  to  be  reconsidered  as  a  need  before 
development  begins.”  [3]  The  COR  training  mentioned  above  is  now  called  project 
manager  training.  [4] 

Recommendations:  The  project  manager  certification  program  should  be 
developed  and  implemented.  Without  a  list  of  requirements  to  become  a  project  manager 
it  is  very  difficult  to  get  a  potential  project  manager  to  accomplish  the  “suggested”  items. 
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Project  managers  should  be  consulted  to  find  out  what  resources  would  be  useful,  and 
these  resources  should  be  provided.  Part  of  the  project  manager  certification  should 
include  a  formal  acquisition  course.  I  recommend  a  course  offered  by  the  Defense 
Systems  Management  College  (DSMC).  The  mission  of  the  DSMC  is  to,  “promote  and 
support  the  adoption  and  practice  of  sound  systems  management  principles  by  the 
acquisition  work  force  through  education  and  training,  research,  consulting,  and 
information  dissemination.”  [5]  “DSMC  is  part  of  the  Defense  Acquisition  University 
(DAU),  which  was  established  in  1992,  and  is  a  consortium  of  15  Department  of  Defense 
(DOD)  education  and  training  institutions.”  [5]  The  course  that  I  believe  would  be  the 
most  beneficial  to  the  project  managers  at  the  JNTF  is  ACQ  101  Fundamentals  of 
Systems  Acquisition  Management.  [6]  “This  course  provides  an  overview  of  the  DOD 
systems  acquisition  process  including  the  basics  of  system  acquisition  program 
management  and  the  developmental  life  cycle  of  a  system  from  inception  to  disposal. 

The  course  covers  and  integrates  system  concept  exploration,  development,  production, 
and  fielding/deployment  using  examples  and  case  studies  from  the  DOD  acquisition 
organizations,  DOD  resource  allocation  processes,  contemporary  issues  in  acquisition, 
and  details  of  the  phases  of  system  developments.  Discussions  are  conducted  on 
requirements  generation,  DOD  5000  series,  procedures,  documentation,  and  current 
issues.  The  course  concludes  with  an  acquisition  strategy  workshop  that  integrates  all  the 
course  material.”  [6]  The  eight  class  day  ACQ  101  course  is  intended  “...for  individuals 
who  have  little  or  no  experience  in  DOD  acquisition  management.  It  has  proved  very 
useful  to  personnel  in  headquarters,  program  management,  functional  or  support  offices, 
and  industry  partners.”  [6]  There  are  no  prerequisites  for  ACQ  101.  [6]  This  course  is 
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available  several  times  each  month  at  various  locations  around  the  country.  [7]  It  will  be 
offered  at  Peterson  AFB  from  25  August  1998  through  3  September  1998.  [7]  The 
schedule  for  ACQ  101  classes  that  start  in  June  1998,  July  1998,  and  August  1998  is 
provided  in  Appendix  C.  [7] 

ACQ  201  Intermediate  Systems  Acquisition  would  be  recommended  for  project 
managers  who  have  already  taken  ACQ  101.  “For  contracting  personnel,  the 
prerequisites  are  ACQ  101,  or  a  combination  of  CON  202,  CON  204  and  CON  210.”  [6] 
ACQ  201  is  a  fourteen  class  day  course  intended  for  students  with  two  to  four  years 
experience.  [6]  “Eighty  percent  of  the  students  who  attend  have  less  than  10  years  of 
experience.”  [6]  “Course  attendees  are  civilian  employees  and  active  duty  service  people 
from  almost  all  of  the  DAWIA  career  paths.”  [6]  DAWIA  is  an  acronym  for  Defense 
Acquisition  Workforce  Improvements  Act.  [8]  The  course  description  for  ACQ  201  is; 
“This  course  provides  journeymen  students  from  the  DAWIA  functional  career  paths  a 
comprehensive  and  integrated  view  of  the  DOD  systems  acquisition  management, 
technical  and  business  processes.  They  become  acquainted  with  the  specialized 
terminology,  concerns,  policies,  and  roles  of  the  primary  acquisition  participants. 
Students  develop  into  practitioners,  better  prepared  to  cooperate  in  a  multifunctional, 
synergistic  environment.  They  are  ready  to  accept  the  empowerment  necessary  to 
implement  the  concepts  of  integrated  product  and  process  development  while  working  in 
program  integrated  product  teams.”  [6]  The  ACQ  201  will  be  offered  at  Peterson  AFB 
from  28  July  1998  through  14  August  1998.  [7]  A  schedule  for  ACQ  201  classes  that 
start  in  June  1998,  July  1998,  and  August  1998  is  also  provided  in  Appendix  C.  [7]  The 
dates  and  the  FULL/NOT  FULL  status  of  the  classes  in  both  of  the  class  schedules  are 


6 


accurate  as  of  13  April  1998.  The  Peterson  AFB  25  August  1998  to  3  September  1998 
ACQ  101  course  will  be  available  over  satellite  and  the  Peterson  AFB  28  July  1998  to  14 
August  1998  ACQ  201  will  have  an  on-site  instructor.  The  point  of  contact  at  Peterson 
Air  Force  Base  for  these  courses  is  Ray  Baldner  (556-2025).  Mr.  Baldner  has  enough 
people  to  fill  the  courses  at  Peterson,  but  depending  on  factors  like  Temporary  Duty 
(TDY)  there  may  be  openings.  Personnel  in  Acquisition  Professional  Development 
Program  (APDP)  eoded  positions  have  priority  in  taking  the  courses.  [8]  Normally  only 
people  in  APDP  coded  positions  will  have  the  TDY  paid  for  but  at  the  end  of  the  year 
people  in  un-coded  positions  may  be  picked  up.  [8]  There  is  no  charge  for  the  courses 
whether  you  are  in  a  coded  or  un-coded  position.  [8]  The  four  schools  that  instruct  the 
courses  are  the:  Defense  Systems  Management  College  (DSMC),  Air  Force  Institute  of 
Technology  (AFIT),  Navy  College  of  Acquisition  Training  (NCAT),  and  Army  Logistics 
Management  College  (ALMC).  [7]  [8]  Any  personnel  can  go  to  a  course  taught  by  any 
of  the  four  schools.  [8]  To  get  in  a  course  at  a  base  other  than  Peterson  Mr.  Matt 
Benavides  can  be  contacted  at  Randolph  Air  Force  Base,  DSN  (487-6580).  [8]  These 
courses  will  be  available  on  the  web  as  self  study  in  late  Summer  1998  or  early  Fall  1998. 
[8] 

What  documents  do  you  use  as  references  in  your  work  as  a  Project  Manager? 

Project  managers  demonstrated  significant  differences  in  their  responses,  all  or 
part  of  each  project  managers  answer  is  below: 

•  “Directive  4200.  Preliminary  briefings  from  sponsor/customer.” 

•  “None,  could  count  Directive  4200,  Project  Manager  Checklist  rarely 
referenced.” 

•  “Developed  a  checklist  to  see  what  the  customer  needs.” 
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•  “The  “Reynolds  Report”,  Previous  version  of  the  DO,  Cost  and  performance 
data  from  finance  (JNTF/POF),...” 

•  “Forms  available  on  the  common  server  (Mogli)  to  do  EE’s,  METOs,  etc. . 
Engineering  Estimates  (EE),  Minimum  Effort  Task  Orders  (METO) 

•  “Primarily  Directive  4200  and  the  Systems  Engineering  Management  Plan 
(SEMP)  DoD  5000.1  and  2.”  Uses  the  web  to  obtain  background  information. 

•  A  personal  reference  called  “Object  Solutions”,  does  not  use  anything  internal 
to  the  JNTF. 

The  Definition  of  the  Delivery  Order  (DO)  is,  “Contract  vehicle  for  each  project  with 
mini-Statement  of  Work  specific  to  that  project...  embodies  the  totality  of  each  project 
from  a  requirements  perspective.  Stand  alone  document  drafted  and  coordinated  by  each 
PM  to  get  ‘their’  work  on  contract.”  [9]  The  Reynolds  Report  is  a,  “Report  generated  as 
a  result  of  an  academic  audit  of  the  ‘then’  technology  modernization  strategy  in  Jan  96. 
Key  points  were  not  to  focus  so  hard  on  the  technology,  but  to  invest  in  more  expertise  in 
contemporary  modeling  and  simulation  methods.  Also  included  very  strong 
recommendations  to  pursue  distributed  computing.”  [9]  The  most  commonly  used 
reference  is  Directive  4200.  Directive  4200  is  a  fairly  short,  user  friendly  document  that 
tells  you  only  what  you  need  to  know.  Directive  4200  is  a  good  model  for  the  type  of 
document  that  is  helpful  to  the  project  managers. 

A  group  at  the  JNTF  is  currently  evaluating  the  JNTF  Overall  Requirements 
Process.  Once  this  group  has  implemented  its  solutions,  the  project  manager  checklist 
should  be  revised  to  reflect  the  changes.  The  Project  Manager  Checklist  should  be 
reviewed  every  six  months  and  kept  current  so  that  it  remains  a  useful  tool  at  all  times. 

Do  you  use  Directive  4200  as  a  reference  in  vour  work  as  a  project  manager? 
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As  described  earlier  Directive  4200  is  the  document  that  describes  the, 
“Processing  of  Joint  National  Test  Facility  Task  Orders.”  [1]  Some  of  the  project 
managers  use  Directive  4200  very  little  and  others  responded  that  they  do  follow  it. 
Directive  4200  was  recently  revised  and  now  may  be  more  useful  to  all  of  the  project 
managers.  One  of  the  project  managers  feels  that  the  examples  are  the  most  important 
part  of  the  document  and  that  real  examples  should  be  added  to  Directive  4200. 

Do  you  use  the  Systems  Engineering  Management  Plan  fSEMP)  CDRL  A078-002  B.  2 
April  1996.  as  a  reference  in  your  work  as  a  project  manager? 

Some  of  the  answers  included,  “Never”,  “No,  did  not  know  it  existed”,  “No,  it  is 
inaccurate,  never  used  it”,  “Not  often”,  and  “Yes,  Can  be  applicable  for  a  common 
understanding,  some  definitions,  probably  needs  to  be  updated.”  The  consensus  was  that 
the  SEMP  is  a  long  (about  150  pages)  outdated  document  that  is  used  very  little.  One 
project  manager  said  a  document  longer  than  20  to  30  pages  is  too  long.  Another  project 
manager  feels  that  the  SEMP  should  be  updated  yearly. 

Recommendations :  It  is  my  understanding  that  a  SEMP  is  usually  created  for  a 
particular  project  and  not  intended  to  cover  all  of  the  projects  like  the  JNTF’s  current 
SEMP.  This  may  be  one  of  the  reasons  that  the  JNTF’s  current  SEMP  is  used  so  little.  I 
suggest  modeling  the  SEMP  after  the  Electronic  Industries  Association/Interim  Standard- 
632.  [10]  An  example  Table  of  Contents  that  follows  EIA/IS-632  is  included  in  appendix 
D.  [11]  Also  the  SEMP  should  be  shortened  and  then  kept  current  through  a  yearly 
update  by  one  person  in  charge  of  the  revision.  If  the  effort  and  cost  required  to  maintain 
the  SEMP  caimot  be  justified  by  the  persoimel  who  would  use  it,  then  I  would 
discontinue  using  the  SEMP. 
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PAYOFF 


What  do  you  like  about  your  job  as  a  project  manager? 

Project  mangers  answered  with  excitement  about  their  jobs  with  statements  such 
as:  “technically  challenging”,  “exciting”,  “allowed  quite  a  bit  of  control  and 
opportunity”,  “given  responsibility  to  make  it  happen”.  Overall  the  project  managers  that 
were  interviewed  appear  to  like  their  jobs.  They  seem  to  feel  empowered  and  in  control 
of  the  work  they  are  doing. 

What  don’t  you  like  about  your  job  as  a  project  manager? 

Project  managers  gave  several  reasons  for  discontentment  with  their  current 

duties: 

•  “Corporate  support  is  poor  for  the  PMs” 

•  “Time  consuming,  labor  intensive” 

•  “No  one  in  the  JNTF  understands  at  the  high-level  how  the  processes  fit 
together”  (engineering  and  contract) 

•  “Very  little  recognition  of  effective  PMs  given  by  the  organization” 

•  “High  work  load” 

•  “Difficult  to  manage  a  large  team  (approximately  35  people)” 

•  “Lack  of  concentrated  focus  and  long-range  planning” 

•  “PMs  reluctant  to  share  information  with  other  PMs  (need  to  prove  the  value 
added  in  coordination)” 

•  “No  strong  incentives  for  PMs  to  work  together” 

•  “Huge  amount  of  time  to  get  a  $1K  or  $400K  project  on  contract,  time  and 
effort  should  correlate  to  the  dollars” 
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•  “We  are  not  able  to  act  as  a  “business”  but  there  is  increasing  pressure  to 
perform  more  corporately” 

Recommendations :  Project  managers  should  meet  weekly  to  share  information 
and  give  up-dates  on  their  projects.  Activities  should  be  set  up  for  team  building;  this 
may  improve  communication  between  the  project  managers.  An  effort  should  be  made 
by  the  project  manager  supervisors  to  publicly  recognize  exceptional  work  by  the  project 
managers. 

PERFORMANCE 

What  are  your  responsibilities  as  a  JNTF  project  manager? 

Project  Managers  indicated  their  responsibilities  as:  defining  the  requirements 
with  the  customer,  planning  a  budget,  getting  the  dollars  in,  overseeing  the  project  and 
timeline,  requirement  coordination  with  contractors.  Essentially  the  project  manager 
must  define  the  requirements  with  the  customer,  pass  the  requirements  on  to  the 
contractors  that  are  going  to  do  the  work,  oversee  all  aspects  of  the  project  and  make  sure 
that  the  customer’s  requirements  are  completed.  This  process  seems  fairly 
straightforward,  but  in  practice  it  can  be  very  complicated  and  time-consuming. 
Depending  on  the  project  that  is  being  worked  and  who  the  customer  is,  getting  the 
requirements  written  down  may  be  difficult. 

Who  is  involved  in  the  requirement  definition  process? 

Most  of  the  project  managers  identified  the  participants  in  the  requirements 
definition  process  as  the  customer,  contractors,  and  the  project  manager.  Some  of  the 
other  people  mentioned  were;  JNTF  Advisory  Assistance  Services  (NAAS)  support, 
JNTF  staff,  and  the  sponsor. 
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How  do  you  define  the  requirements  for  a  project? 


One  project  manager  says  they,  “Start  with  idea,  work  with  customer  to  develop 
high  level  approach.”  Different  project  managers  used  a  variety  of  different  terminology 
for  describing  the  steps  in  the  process  including:  A-spec,  Operational  Concept  document, 
working  groups,  configuration  change  board,  In-Process  Review,  business  plan,  and 
Integrated  Product  Teams. 

Recommendations :  The  project  managers  should  meet  and  talk  about  the  steps 
they  use  and  decide  on  the  most  efficient  process  and  then  use  the  same  terminology  to 
describe  the  steps.  A  standard  process  with  standard  terminology  would  make 
communication  among  all  of  the  people  involved  easier.  Because  the  project  managers 
all  have  different  projects  with  different  types  of  customers,  it  may  be  hard  to  standardize 
the  process.  An  attempt  should  be  made  to  find  a  process  that  fits  the  majority  of  the 
projects  and  the  others  can  adapt  the  process  to  fit  their  project. 

One  item  which  seems  essential  is  the  Operational  Concept  Document  (OCD). 
From  the  OCD,  Measures  of  Effectiveness,  Environments,  and  Constraints  will  flow  one 
of  three  documents.  They  are  listed  here  in  order  of  increasing  detail  required  to  write 
them:  Operational  Requirements  Document  (ORD),  Capstone  Requirements  Document 
(CRD),  Functional  Requirements  Document  (FRD).  At  a  minimum  the  ORD  must  be 
written.  I  have  included  in  appendix  E  two  attachments  from  Air  Force  Instruction  (AFI) 
10-601  31  May  1994  (Operations)  “Mission  Needs  and  Operational  Requirements 
Guidance  and  Procedures”.  [12]  Attachment  7  from  AFI  10-601  Describes  the  ORD 
(Procedures  and  Format).  [12]  Attachment  8  from  AFI  10-601  describes  the  ORD 
Requirements  Correlation  Matrix  (RCM)  (Procedures  and  Format).  [12]  I  suggest  using 


12 


the  RCM  as  the  tool  to  keep  track  of  the  project  requirements  and  the  changes  to  the 
requirements  throughout  the  projects  lifecycle. 

One  of  the  project  managers  talked  about  a  “wailing  &  grinding  of  teeth”  between 
the  project  manager  and  the  contractors.  To  avoid  this  problem  the  contractors  should  be 
involved  in  the  requirements  refinement  process.  The  first  meeting  between  the  customer 
and  the  project  manager  should  also  include  the  contractors  that  will  be  involved. 

In  the  requirement  definition  process  are  only  requirements  written  down,  or  are  solutions 
included  in  the  list  also? 

It  seems  that  a  common  problem  for  all  people  involved  in  requirements 
definition  is  that  solutions  are  thought  of  before  a  requirement  is  written  down.  If  this 
occurs  then,  the  actual  requirement  may  never  be  defined.  Some  of  the  project  managers 
said  that  solutions  were  not  put  down  in  the  requirements  definition  process,  and  some 
said  that  solutions  were  included  sometimes.  One  project  manager  said,  “It’s  only  natural 
to  have  a  preconceived  notion  of  the  solution.”  Another  project  manager  said, 
“Sometimes  possible  solutions  are  looked  at  for  cost  or  interface  considerations.” 

Recommendations :  Even  with  the  temptation  to  come  up  with  solutions  early  in 
the  process,  it  is  better  to  wait  so  that  no  ideas  are  lost  because  a  solution  has  already 
been  defined. 

Who  is/are  your  customerfsl  and  how  much  do  they  participate  in  the  project? 

As  might  be  expected,  project  managers  had  their  own  specific  customers.  Some 
of  the  customers  included:  Ballistic  Missile  Defense  Organization  (BMDO),  United 
States  Space  Command,  Air  Force  Space  Command,  JNTF  projects  and  project 
managers.  The  levels  of  participation  by  the  customers  varied  from  not  enough 
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participation  to  too  much  participation.  I  would  say  that  a  highly  interactive  relationship 
between  the  customer  and  the  project  manager  is  better  than  not  enough  interaction. 

What  would  you  change  about  the  process  used  by  the  Project  Managers,  and  how  would 
you  change  it? 


Most  of  the  project  managers  had  a  lot  to  say  in  their  response  to  this  question. 

•  “Recommend  anything  that  would  speed  up  process,  need  to  streamline  it,  too 
many  people  involved,  cut  down  the  number  of  people  but  would  require  an 
un-biased  mediator  who  is  not  associated  with  the  projects  and  not  affected  by 
the  dollars.  Better  off  tracking  performance  rather  than  trying  to  have  perfect 
descriptions.” 

•  “Process  should  be  defined  better  by  using  possibly  continuity  folders,  which 
currently  are  not  used,  and  use  a  program  manager  checklist.” 

•  “Need  a  better  division  of  labor.  Better  job  of  getting  justifiable  requirements 
in  the  hands  of  people  doing  long  term  planning.” 

•  “I  would  Force  top  level  policies  to  be  drafted  and  enforce  that  require  PMs  to 
coordinate  their  efforts  more  effectively  and  use  a  single,  highly  visible 
requirements  process  that  would  facilitate  a  more  “corporate”  solution  instead 
of  Stove-piping.  I  would  also  require  periodic  reviews  for  governments  and 
contractors  to  get  greater  visibility  into  the  projects’  critical  objectives, 
progress,  and  issues.” 

•  “Make  the  process  more  standardized  with  more  influence  based  on 
management  requirements  instead  of  strictly  following  government 
contractual  desires.  Force  standardization  and  follow-up  to  ensure  they  are 
managing  consistently.  Reaffirming  centralized  control  and  accountability 
would  go  a  long  way.  Money  does  not  flow  through  management  channels.” 

•  The  amount  of  time  and  resources  used  to  work  with  the  customer  trying  to 
get  buy-in  early,  to  date,  is  mostly  self-imposed. 

•  “Have  already  started  to  change  in  the  department,  set  aside  a  group  whose 
primary  job  is  requirements  definition  (not  his  developer).  Would  take 
BMDO/TOM  out  of  requirement  definition  process  allow  JNTF  to  manage 
process  not  have  BMDO/TOM  involved.” 

It  seems  like  more  centralized  control  is  needed.  The  JNTF  group  working  on 

requirements  appears  to  favor  this  approach.  Notes  from  one  of  their  meetings  refer  to 
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using  the  Deputy  Commander  for  Customer  Integration  (JNTF/CI)  as  the  single  entry 
point  for  all  requirements  to  the  JNTF. 

What  do  you  like  about  the  process  used  bv  the  project  managers? 

Some  of  the  benefits  the  project  managers  found  with  the  current  process  are  cited 

below. 

•  “Open  process  freedom” 

•  “We  do  eventually  get  stuff  on  contract  and  projects  completed” 

•  “Talking  with  the  other  PMs  can  give  good  ideas  and  can  find  out  about 
changes  this  way” 

•  .  .Very  good  interaction  with  customers  and  good  customer  focus” 
Recommendations:  Overall  project  managers  seem  to  like  that  they  can  do  their 

jobs  without  interference,  but  I  believe  more  standardization  of  the  process  used  would  be 
helpful.  Also  better  interaction  and  idea  sharing  between  the  project  managers  is  needed. 

Discussion  of  Limitation 

This  paper  discusses  issues  specifically  related  to  the  project  manager  processes 
used  at  the  JNTF.  Because  not  all  of  the  JNTF  project  managers  were  included  in  the 
survey,  additional  useful  information  could  be  obtained  by  extending  the  survey  to  them. 
Conclusions 

The  suggested  areas  for  improvement  are: 

•  Development  and  implementation  of  a  Project  Manager  Certification 
Program.  Part  of  PM  certification  should  include  attendance  at  ACQ  101. 

The  second  course  ACQ  201  could  be  required  after  four  years  of  experience 
as  a  project  manager. 
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•  Evaluate  the  usefulness  of  the  SEMP  and  take  the  appropriate  action  to  revise 
the  SEMP  continually  or  discontinue  use  of  the  SEMP. 

•  Better  communication  between  the  project  managers  through  weekly  PM 
meetings  and  team  building  exercises  at  work  and  outside  of  work. 

•  Use  the  Requirements  Correlation  Matrix  as  a  way  to  track  requirements 
throughout  the  project. 

•  Involve  integral  personnel  at  all  critical  steps  to  avoid  confusion  and 
redundancy. 
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Appendix  C 


DSMC  Summer  1998  Schedule  for 
ACQ  101  and  ACQ  201 


DSMC  ACQ  101  Schedule  for  Summer  1998 
START  FINISH  I  FULL?  I  SCHOOL  I  LOCATION 


Jun2 

Jun  11 

NO 

DSMC 

DSMC,  Boston,  MA 

Jun  9 

Jun  18 

FULL 

DSMC 

FT  Belvoir,  VA  DOD 

Jun  16 

Jun  25 

NO 

AFIT 

USAF  Instit  of  Tchnlgy,  WRIG 

Jun  16 

Jun  25 

NO 

AFIT 

Hanscom  AFB,  MA  USAF 

Jun  16 

Jun  25 

NO 

AFIT 

Kelly  AFB,  TX 

Jun  16 

Jun  25 

FULL 

ALMC 

Philadelphia,  PA  NAVY 

Jul  7 

Jul  16 

NO 

DSMC 

DSMC  FT  Belvoir,  VA 

Jul  7 

Jul  16 

NO 

ALMC 

ALMC,  FT  LEE  VA 

Jul  14 

Jul  23 

NO 

NCAT 

Patuxent  River,  MD  NAVY 

Jul21  JulSO  NO  DSMC  DSMC,  Huntsville,  AL 

Jul21  JuTSO  FULX  ALMC  Warren,  MI  ARMY 

Jul  28  Aug  6  NO  AFIT  USAF  Instit  of  Tchnlgy,  WRIG 

Mis  Aug6  FUlX  AFiT  Edwards  AFB,  CAUSAF 

Jul 28  Aug6  NO  AFiT  Brooks  AFB,  TX USAF 

Jul  28  Aug  6  NO  AFIT  Langley  AFB,  VA  USAF 

Aug  4  Aug  13  NO  DSMC  DSMC  FT  Belvoir,  VA 

Aug  4  Aug  13  FULL  DSMC  FT  Monmouth,  NJ  ARMY 

Aug  4  Aug  13  NO  ?JCAT  Robins  AFB,  GA  USAF 

Aug  4  Aug  13  NO  ALMC  ALMC,  FT  Lee  VA 

Aug  11  Aug  20  NO  DSMC  WPAFB,  OH  AF 


Aug  18 


Aug  27 


NO 


DSMC 


EL  Segundo,  CA  DOD 


DSMC  ACQ  201  Schedule  for  Summer  1998 


START 

FINISH 

FULL? 

SCHOOL 

LOCATION 

Jun  2 

Jun  19 

NO 

DSMC 

DSMC,  Los  Angeles,  CA 

Jun  2 

Jun  19 

NO 

DSMC 

DSMC  FT  Belvoir,  VA 

Jun  2 

Jun  19 

NO 

AFIT 

USAF  Instil  of  Tchnlgy,  WRIG 

Jun  2 

Jun  19 

NO 

NCAT 

Eglin  AFB,  FL  USAF 

Jun  2 

Jun  19 

NO 

NCAT 

Kelly  AFB,  TX 

Jun  9 

Jun  26 

NO 

DSMC 

DSMC  FT  Belvoir,  VA 

Jun  9 

Jun  26 

FULL 

DSMC 

FT  Monmouth,  NJ  ARMY 

Jun  9 

Jun  26 

FULL 

NCAT 

Cherry  Point,  NC  NAVY 

Jun  29 

Jul  ly 

NO 

DSMC 

DSMC  FT  Belvoir,  VA 

Jun  29 

Jul  ly 

NO 

DSMC 

Huntsville,  AL  ARMY 

July 

Jul  24 

NO 

DSMC 

DSMC  FT  Belvoir,  VA 

July 

Jul  24 

NO 

AFIT 

Point  Mugu,  CA  NAVY 

July 

Jul  24 

NO 

NCAT 

Dallas,  TX  DOD 

Jul  14 

Jul  31 

NO 

NCAT 

Patuxent  River,  MD  NAVY 

Jul21 

Augy 

NO 

DSMC 

DSMC  FT  Belvoir,  VA 

Jul21  Aug?  NO  NCAT  FT  Meade,  MD  USAF 

JunS  Aug  14  NO  DSMC  DSMC  FT  Belvoir,  VA 

JuTlS  Aug  14  NO  NCAT  Peterson  AFB,  CO  USAF 

Aug  4  Aug  21  NO  DSMC  Orlando,  FL  ARMY 

Alip  AugTi  NO  NCAT  Robins  AFB,  GA  USAF 

Aug  11  Aug  28  NO  DSMC  DSMC  FT  Belvoir,  VA 

Aug  11  Aug  28  NO  DSMC  Huntsville,  AL  ARMY 

Aug  11  Aug  28  NO  AFIT  USAF  Instit  of  Tchnlgy,  WRIG 

Aug  18  Sep4  NO  DSMC  DSMC,  Boston,  MA 

Aug  18  Sep  4  NO  DSMC  DSMC  FT  Belvoir,  VA 
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Attachments  7  and  8  from  AFI 10-601 


Attachment  7 

OPERATIONAL  REQUIREMENTS  DOCUMENT  (ORD)  (PROCEDURES  AND  FORMAT) 
Section  A7A — ORD  Procedures 

A7.1.  Procedures  in  Preparing  an  ORD.  The  ORD  is  a  formatted  statement  that  contains  performance 
(operational  effectiveness  and  suitability)  and  related  operational  parameters  for  the  proposed  concept  or 
system.  This  attachment  contains  DoD  and  Air  Force  guidance  on  how  to  prepare  an  ORD.  Relevant 
information  in  an  ORD  will  vary  based  on  specific  subject  matter  and  maturity  of  a  program.  An  ORD  I, 
for  example,  will  contain  only  basic,  limited  information  required  for  a  MS  I  decision.  Later  milestones 
will  need  a  much  higher  level  of  detail  as  system-specific  information  becomes  known.  A  requirements 
correlation  matrix  (RCM)  is  a  mandatory  attachment  to  all  Air  Force  and  Air  Force-lead  ORDs  (see 
attachment  8  for  RCM  procedures  and  format).  NOTE:  System  Operational  Requirements  Document 
(SORD)  to  ORD  conversion  policy:  SORDs  for  existing  programs  must  be  reaccomplished  in  the  ORD 
format  before  the  next  scheduled  Milestone  decision.  SORDs  for  programs  that  have  not  proceeded 
beyond  Milestone  11:  Convert  SORDs  to  ORDs  prior  to  the  Milestone  II  decision.  SORDs  for  programs 
beyond  Milestone  II:  If  the  MS  II  decision  was  prior  to  August  1991,  MAJCOMs  may  update  the  existing 
SORD  between  Milestone  decision  points  as  necessary.  However,  if  the  SORD  is  updated,  the  RCM 
must  be  reaccomplished  to  comply  with  the  format  specified  in  attachment  8  of  this  instruction.  All  pro¬ 
grams  must  convert  SORDs  to  the  ORD  format  to  support  a  MS  III  decision.  SORDs  for  programs 
beyond  MS  III:  SORDs  may  be  updated  as  necessary;  however,  the  RCM  must  be  reaccomplished  to 
comply  with  the  format  specified  in  attachment  8  of  this  instruction.  In  order  to  facilitate  the  staffing  and 
approval  process,  it  is  highly  recommended  that  the  latitude  for  updating  SORDs,  instead  of  converting  to 
an  ORD,  be  invoked  by  the  user  only  for  minor  changes.  The  staffing  and  approval  process  for  SORD 
updates  is  the  same  as  described  in  paragraphs  A7.2.1,  A7.2.2,  and  A7.2.3.  However,  CSAF  approval  for 
SORD  updates  is  required  only  for  significant  requirements  changes  (as  determined  by  HQ  USAF/XOR). 

A7.1.1.  Each  concept  proposed  at  MS  I,  Concept  Demonstration  Approval,  for  continued  evaluation 
during  Phase  I,  Demonstration  and  Validation,  will  be  described  in  the  ORD  in  terms  of  system  char¬ 
acteristics  and  capabilities  that  define  the  system  needed  to  satisfy  the  MNS.  Use  the  following 
descriptions/defmitions  of  terms  to  assist  in  developing  the  requirements: 

A7. 1.1.1.  MOEs  should  be  developed  to  quantify  how  well  alternatives  satisfy  the  operational 
need  qualitatively  described  in  the  MNS.  These  MOEs  should  be  developed  during  the  Phase  0 
COEA  process  and  should  be  included  in  the  ORD.  MOEs  play  a  vital  part  in  linking  the  COEA, 
APB,  ORD,  and  TEMP.  Since  MOEs  are  rarely  amenable  to  end-to-end  tests,  the  capabilities 
(MOP)  and  characteristics  (design  features)  in  the  initial  and  subsequent  ORDs  should  be  refined 
to  a  level  of  specificity  that  allows  development  and  operational  testing  to  assess  system  effective¬ 
ness.  (CJCS  MOP  77). 

A7. 1 . 1 .2.  The  system  characteristics  and  capabilities  in  the  ORD  will  be  tailored  to  the  concept 
(e.g.,  satellite,  aircraft,  missile,  weapon,  etc.)  and  will  reflect  system-level  performance  character¬ 
istics  and  capabilities.  Applicable  environmental  conditions  will  also  be  identified. 

A7.1.1.2.1.  System  capabilities  are  measures  of  performance  such  as  range,  lethality, 
maneuverability,  etc. 

A7.1. 1.2.2.  System  characteristics  are  design  features  such  as  weight,  size,  shape,  etc. 
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A7.1.1.2.2.1.  Critical  system  characteristics  are  a  special  category  of  characteristics 
that  are  historically  design,  cost,  and  risk  drivers;  and  therefore,  they  require  early  identifi¬ 
cation  to  facilitate  cost  and  risk  reduction  and  cost-performance  tradeoffs.  Critical  system 
characteristics  include  such  areas  as  electromagnetic  pulse  hardening,  energy  efficiency, 
transportability,  interoperability,  stealth,  electronic  counter-countermeasures  (ECCM), 
etc.  (See  DoD  Instruction  5000.2/ Air  Force  Supplement  1  and  paragraph  4c,  section  B,  this 
attachment.) 

A7.1.1.3.  A  threshold  is  a  minimum  acceptable  operational  value  for  a  system  capability  or  char¬ 
acteristic  which,  in  the  user’s  judgment,  is  necessary  to  provide  an  operational  capability  that  will 
satisfy  the  mission  need  (DoD  Instruction  5000.2/Air  Force  Supplement  1). 

A7.1.1.4.  An  objective  is  a  value  beyond  the  threshold  that  could  potentially  have  a  measurable, 
beneficial  impact  on  capability  or  operations  and  support  above  that  provided  by  the  threshold 
value  (e.g.,  additional  range  that  might  reduce  the  number  of  refueling  systems  required)  (DoD 
Instruction  5000.2/ Air  Force  Supplement  1).  An  objective  value  may  be  the  same  as  the  threshold 
when  an  operationally  significant  increment  above  the  threshold  is  not  identifiable  or  useful. 

A7.1.1.5.  Key  performance  parameters  describe  those  capabilities  and  characteristics,  includ¬ 
ing  selected  critical  system  characteristics,  so  significant  that  failure  to  meet  the  threshold  is  cause 
for  the  concept  or  system  to  be  reevaluated  or  the  program  to  be  reassessed  or  terminated  (DoD 
Instruction  5000.2/Air  Force  Supplement  1  and  CJCS  MOP  77).  Key  performance  parameters 
are  extracted  from  the  ORD  and  are  included  in  the  performance  section  of  the  APB  at  each 
milestone.  Considerations  for  identifying  key  performance  parameters  are: 

•  They  must  be  important. 

•  They  must  be  warfighting  oriented. 

•  They  must  be  measurable,  achievable  (realistic),  and  testable. 

•  The  numbers  and  percentages  must  be  explainable  by  analysis. 

•  They  must  be  in  the  ORD  and  the  Acquisition  Program  Baseline. 

•  The  user  must  be  willing  to  consider  cancelling  the  program  if  the  threshold  is  not  met.  (Source: 
JROC  Secretariat) 

A7.1.2.  The  ORD  will  be  updated  and  expanded  for  MS  II,  Development  Approval,  to  include  thresh¬ 
olds  and  objectives  for  more  detailed  and  refined  performance  capabilities  and  characteristics  which 
are  based  on  the  results  of  tradeoff  studies  and  testing  conducted  during  Phase  I,  Demonstration  and 
Validation. 

A7. 1.2.1.  After  MS  II,  the  ORD  will  be  modified  only  as  a  result  of  a  change  in  the  MNS  or  cost- 
schedule-performance  tradeoffs  conducted  during  Phase  II,  Engineering  and  Manufacturing 
Development. 

A7. 1.2.2.  Key  performance  parameters  extracted  from  the  ORD  will  be  included  in  the  perfor¬ 
mance  section  of  the  Development  Baseline  (APB)  at  MS  II  and  the  Production  Baseline  (APB)  at 
MS  III. 

A7.1.3.  The  ORD  will  be  used  to  develop  contract  specifications  during  each  acquisition  phase. 
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A7.2.  Preparation  and  Submission.  HQ  USAF/XOR  will  direct  preparation  of  the  initial  ORD  in  the 
concept  study  PMD  which  assigns  responsibilities,  directs  actions,  and  assigns  suspenses.  The  using 
command  is  normally  the  OPR  for  the  ORD.  The  OPR  will  prepare  the  first  ORD  (consistent  with  COEA 
accomplishment)  during  Phase  0,  Concept  Exploration  and  Definition,  for  one  or  more  preferred  concepts 
to  be  proposed  at  MS  I.  The  OPR  will  work  with  the  OCRs  at  the  supporting,  implementing,  and  partici¬ 
pating  commands  as  well  as  designated  test  agency  to  produce  the  ORD. 

A7.2.1.  Review  and  Staffing.  After  developing  the  draft  ORD,  the  OPR  will  conduct  a  draft  "for 
comment"  phase,  by  distributing  the  ORD  according  to  attachment  9  for  Air  Force-wide  review.  Use 
the  applicable  cover  sheet  (attachment  4)  and  a  command  transmittal  letter  to  include  relevant  ORD 
control  information,  to  identify  the  potential  ACAT  level,  and  any  other  amplifying  instructions  or 
information  pertinent  to  the  document  (e.g.,  backfill  document,  SORD  to  ORD  conversion  only,  doc¬ 
ument  being  prepared  for  Milestones  I,  II,  and  III  combined,  etc.)  HQ  USAF/XOR  will  obtain  HQ 
USAF  and  SAF  directorate  level  (2  star)  review.  The  comments  obtained  during  HQ  USAF  and  SAF 
review  will  be  consolidated  and  forwarded  to  the  ORD  originator,  normally  within  45  days  from 
receipt  of  the  document.  These  comments  will  be  qualified  as  critical,  substantive,  or  administrative. 
Failure  to  address  critical  comments  may  be  cause  for  nonconcurrence  on  the  final  document.  Sub¬ 
stantive  comments  should  be  addressed,  but  failure  to  do  so  will  not  necessarily  result  in  nonconcur¬ 
rence  on  the  final  document.  Air  Force- wide  addressees  must  respond  to  the  originator  within  45  days 
from  receipt  of  the  document.  After  completing  the  draft  "for  comment"  phase,  the  ORD  originator 
must  update  the  ORD,  to  include  relevant  inputs,  and  forward  the  final  document  (without  the  MAJ- 
COM  or  using  commander’s  signature)  to  HQ  USAF/XORJ  under  appropriate  command  transmittal 
letter.  The  ORD  must  be  accompanied  by  the  disposition  of  each  of  the  critical  and  substantive  com¬ 
ments  made  by  HQ  USAF  and  SAF  agencies  during  the  draft  "for  comment"  review.  HQ  USAF/XOR 
will  obtain  final  Deputy  Chief  of  Staff  level  coordination  on  the  document,  normally  within  30  days 
from  receipt  of  the  document,  and  notify  the  originator  that  the  final  document  is  ready  for  validation 
and  submission  for  CSAF  approval. 

A7.2.2.  Validation  and  Approval.  Upon  notification  that  the  final  document  is  ready  to  submit  for 
CSAF  approval,  the  applicable  MAJCOM  or  originator  will  validate  the  ORD  by  obtaining  the  com¬ 
mander’s  signature  on  the  cover  sheet  (attachment  4).  MAJCOMs  or  originators  then  forward  the 
ORD  to  HQ  USAF/XORJ  to  submit  for  CSAF  approval,  normally  obtained  witbin  15  days  from 
receipt  of  the  MAJCOM-validated  document.  HQ  USAF/XOR  will  forward  a  copy  of  the  CSAF 
approved  document  and  approval  memorandum  to  the  ORD  originator. 

A7.2.3.  ORD  originators  will  send  CSAF-approved  ORDs  to  the  applicable  organizations  listed  at 
attachment  9.  After  publication,  the  OPR  will  not  change  the  ORD  without  coordinating  with  the 
applicable  OCRs.  NOTE:  Any  changes  to  an  approved  ORD  and  RCM  must  be  resubmitted  for 
HQ  USAF  review  and  may  require  CSAF  approval  (dependent  on  the  level  or  impact  of  the 
change). 

A7.2.4.  Preparation,  review,  coordination,  and  approval  for  subsequent  ORDs  or  ORD  updates  will 
normally  be  the  same  as  for  the  first  ORD.  The  OPR  will  update  the  ORD  before  and,  if  necessary, 
after  Milestone  and  Summit  reviews. 

A7.3.  ORD  Numbering.  In  order  to  provide  linkage  and  traceability,  the  ORD  title  will  contain  the  same 
number  as  assigned  to  the  MNS  to  which  it  responds,  with  the  addition  of  the  Milestone  number  for  which 
the  ORD  is  being  prepared.  (Example:  CAF  MNS  001-XX  requires  a  CAF  ORD  001-XX-I  for  a  MS  I 
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decision.  Subsequent  ORDs  prepared  for  Milestones  II  and  III  would  be  numbered  CAP  ORD  001-XX- 
II  and  CAP  ORD  001-XX-III,  respectively.  If  there  are  several  different  projects  or  programs  generated 
from  the  same  MNS,  initiators  will  identify  the  subsequent  requirements  documents  as  described  above 
with  the  addition  of  the  suffixes  A,  B,  etc.,  to  separate  each  project  (CAP  ORD  001-XX-IA  and  CAP 
ORD  001-XX-IIB).  Documents  being  revised  between  Milestone  decisions  should  be  identified  as  CAP 
ORD  001-XX-I  (Revision  1,  January  19, 199X).  If  the  initial  ORD  is  being  prepared  for  a  program  going 
directly  from  a  MS  0  to  MS  II  or  III,  the  ORD  should  be  numbered  CAP  ORD  001-XX-I/II  for  a  MS  II 
decision  or  CAP  ORD  001-XX-I/II/III  for  a  MS  III  decision. 

Section  A7B — ORD  Format 

A7.4.  This  attachment  includes  DoD  and  Air  Porce  guidance.  Note:  An  asterisk  (*)  denotes  Air  Porce 
guidance. 

OPERATIONAL  REQUIREMENTS  DOCUMENT  (ORD)  FOR  (PROGRAM  TITLE) 

1.  General  Description  of  Operational  Capability: 

a.  Describe  the  mission  area,  the  type  of  system  proposed,  and  the  anticipated  operational  and  support 
concepts  in  sufficient  detail  for  program  and  logistics  support  planning.  Include  a  brief  summary  of  the 
MNS  and  identify  it  by  the  assigned  MAJCOM  number.  If  a  MNS  did  not  precede  the  ORD,  explain  the 
source  directing  the  effort  or  program  and,  if  applicable,  the  process  that  investigated  alternatives  for  sat¬ 
isfying  the  mission  need  and  developing  operational  requirements.  If  the  program  was  top-down  directed, 
state  that  fact  and  the  directing  organization. 

*b.  The  user  must  prepare  a  Requirements  Correlation  Matrix  (RCM)  as  an  attachment  to  the  ORD.  (See 
attachment  7  for  RCM  procedures  and  format.) 

2.  Threat: 

a.  Identify  potential  enemy  capabilities—doctrine,  strategy,  tactics,  organization,  equipment  and  military 
forces— that  could  defeat,  degrade,  or  destroy  proposed  concept  or  system  effectiveness.  Summarize  the 
threat  and  threat  environment  based  on  DIA  projections  that  extend  10  to  20  years  in  the  future.  The  ORD 
threat  assessment  will  contain  the  following  sections:  Operational  Threat  Environment,  System  Specific 
Threats  (at  IOC  and  IOC  plus  10  years).  Reactive  Threats,  and  Targets  (if  applicable). 

b.  For  major  defense  acquisition  programs  (ACAT  I),  reference  the  HQ  USAF/IN  approved  and  DIA  val¬ 
idated  System  Threat  Assessment  Report  (STAR).  In  some  nonwarfighting  systems,  the  threat  may  be 
listed  as  not  applicable.  *The  STAR  addresses  operational  threats  to  a  resource  (such  as  a  surface-to-air 
missile  threat  to  a  fighter)  as  well  as  threat  countermeasures.  The  STAR  must  include  the  operational 
threat  and  the  ground  threat  posed  by  terrorists  and  other  opposing  forces. 

3.  Shortcomings  of  Existing  System.  Describe  why  existing  systems  cannot  meet  current  or  projected 
requirements  (do  not  describe  a  proposed  system). 

4.  Capabilities  Required.  This  section  should  describe,  in  operational  terms,  the  required  system  perfor¬ 
mance  capabilities  and  characteristics.  The  measures  of  effectiveness  and  the  related  MOPs  identified 
during  Phase  0  concept  studies  or  the  COEA  process  should  also  be  included  in  this  section  of  the  ORD. 
At  MS  I,  the  ORD  may  be  brief,  with  some  capabilities  and  characteristics  to  be  determined  and  subject 
to  later  refinement.  Consider  all  elements  and  subsystems  to  develop  a  total  integrated  systems  approach. 
Specify  each  capability  and  characteristic  in  terms  of  a  threshold  value  required  to  satisfy  the  mission 
need  and  an  objective  value.  Capabilities  and  characteristics  with  threshold  values  are  eligible  for  inclu- 
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sion  in  the  performance  section  of  the  Acquisition  Program  Baseline  (APB)  as  key  performance  parame¬ 
ters;  for  testing  during  development,  test,  and  evaluation  (DT&E);  and  for  testing  during  operational  test 
and  evaluation  (OT&E).  These  values  will  be  weighed  against  what  is  operationally  acceptable  and  what 
is  considered  technically  achievable  while  providing  the  program  manager  as  much  latitude  and  flexibil¬ 
ity  as  possible. 

a.  System  Performance: 

(1)  Include  system  performance  parameters  such  as  mission  planning  needs,  range,  accuracy,  payload, 
speed,  mission  reliability,  etc.  Describe  mission  scenarios  (wartime  and  peacetime,  if  different)  in  terms 
of  mission  profiles,  employment  tactics,  and  environmental  conditions  (all  inclusive:  natural  and  man¬ 
made  [i.e.,  weather,  countermeasures,  ocean  acoustics,  etc.]). 

*(2)  Cite  the  SEEK  EAGLE  (SE)  needs  and  requirements  the  new  aircraft  and  (or)  stores  must  have  (see 
attachment  1 1,  for  SE  definition).  Identify  the  items  of  critical  information  (capabilities  and  limitations  of 
weapon  systems  to  be  controlled  or  protected  from  enemy  intelligence  collection). 

b.  Logistics  and  Readiness.  Include  measures  for  mission  capable  rate,  operational  availability,  fre¬ 
quency  and  duration  of  preventive  or  scheduled  maintenance  actions,  etc.  Describe  in  terms  of  mission 
requirements,  considering  wartime  and  peacetime  logistics  operations.  Identify  combat  support  require¬ 
ments,  including  battle  damage  repair  capability,  mobility  requirements,  expected  maintenance  man¬ 
power  and  skill  levels,  and  surge  and  mobilization  capabilities.  *AFI  10-602  provides  specific  guidance 
on  defining  these  requirements. 

c.  Critical  System  Characteristics.  As  a  minimum,  and  where  applicable,  address  ECCM  and  Wartime 
Reserve  Modes  (WARM)  requirements;  conventional,  initial  nuclear  weapons  effects,  and  nuclear,  bio¬ 
logical,  and  chemical  (NBC)  survivability;  natural  environmental  factors  (such  as  climatic,  terrain,  and 
oceanographic  factors);  and  electromagnetic  compatibility  and  frequency  spectrum  assignment  for  sys¬ 
tems  operating  in  the  electromagnetic  spectrum.  Define  the  expected  mission  capability  (i.e.,  full,  percent 
degraded,  etc.)  in  the  various  environments  and  for  the  applicable  threat  scenarios.  Include  applicable 
safety  parameters  related  to  system,  nuclear,  explosive,  and  flight  safety.  Identify  communications,  infor¬ 
mation,  and  physical  and  operational  security  needs.  (Selected  critical  system  characteristics  may  be 
included  as  key  parameters  in  the  performance  section  of  the  APB.) 

*Identify  arms  control  treaty  compliance  requirements. 

5.  Integrated  Logistics  Support  (ILS).  Establish  organizational,  intermediate  (if  required),  and  depot 
level  support  objectives  for  initial  and  full  operational  capability  (API  10-602).  *The  OPR  and  support¬ 
ing  command  OCR  will  develop  and  expand  ILS  requirements  and  planning  in  the  Integrated  Logistics 
Support  Plan  (ILSP)  and  collect  and  process  ILS  information  in  the  Logistics  Management  Information 
System  (LMIS).  ILS  planning  will  be  accomplished  at  the  subsystem  level  for  each  acquisition. 

a.  Maintenance  Planning.  Identify  maintenance  tasks  to  be  accomplished  and  time  phasing  for  depot 
maintenance,  including  programmed  depot  maintenance  and  surveillance  inspections  such  as  nuclear 
hardness  and  structural  integrity.  Describe  the  planning  approach  for  contract  versus  organic  repair. 
Develop  maintenance  concepts,  using  Repair  Level  Analysis  (RLA)  trade  studies.  Determine  mainte¬ 
nance  strategy  for  reparable,  commercial  nondevelopmental  items  (NDI). 

b.  Support  Equipment.  Standard  support  equipment  to  be  used  by  the  system  will  be  defined,  maximiz¬ 
ing  the  use  of  commercial  NDIs  and  families  of  automated  test  equipment  (ATE).  Test  and  fault  isolation 
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capabilities  desired  of  automatic  test  equipment  will  be  described  at  all  levels,  expressed  in  terms  of  real¬ 
istic  and  affordable  probabilities  and  confidence  levels. 

c.  Human  Systems  Integration  (HSI).  The  operational  and  maintenance  training  concept  (pipeline, 
training  devices,  embedded  training  and  onboard  training,  interactive  courseware)  will  be  briefly 
described.  Identify  manpower,  personnel,  and  training  constraints.  Establish  objectives  and  thresholds,  if 
applicable,  for  manpower  (force  structure  and  end  strength),  personnel  (numerical  and  skill  level),  train¬ 
ing,  and  safety.  Specify  manpower  and  training  methodologies  to  be  used  (i.e.,  HARDMAN). 

d.  Computer  Resources.  Identify  computer  resource  constraints  (examples  include  language,  computer, 
data  base,  architecture,  or  interoperability  constraints).  Address  mission  critical  and  support  computer 
resources,  including  automated  test  equipment.  Describe  the  capabilities  desired  for  integrated  computer 
resources  support.  Identify  any  unique-user  interface  requirements,  documentation  needs,  and  special 
software  certifications. 

e.  Other  Logistics  Considerations.  Describe  the  provisioning  strategy  for  the  system.  Specify  any 
unique  facility  and  shelter  requirements.  Identify  special  packaging,  handling,  and  transportation  consid¬ 
erations.  Define  unique  data  requirements  such  as  engineering  data  for  depot  support  and  technical  orders 
for  the  system  and  depot.  *Include  Computer-aided  Acquisition  Logistics  Support  (CALS)  requirements 
for  technical  data.  Identify  the  use  of,  and  minimize  need  for  hazardous  materials.  For  additional  infor¬ 
mation,  see  AFPD  21-3,  AFPD  24-6,  AFR  71-1,  and  AFR  80-18. 

6.  Infrastructure  Support  and  Interoperability.  Discuss  interfacing  systems  (at  the  system  or  sub¬ 
system,  platform,  and  force  levels),  specifically  those  related  to  command,  control,  communications,  and 
intelligence  (C3I),  transportation  and  basing,  and  standardization  and  interoperability.  Identify  compan¬ 
ion  ORD  and  other  Services  that  may  have  similar  requirements.  Include  the  joint  potential  designator 
(joint,  joint  interest,  or  independent)  established  during  the  Service  harmonization  process  (see 
paragraph  3J)*NOTE:  HQ  USAF/XOR  will  pass  the  joint  potential  designation  to  J-7. 

a.  Command,  Control,  Communications,  and  Intelligence.  Describe  how  the  system  will  be  integrated 
into  the  C3I  architecture  forecasted  to  exist  at  the  time  the  system  will  be  fielded.  Include  data  require¬ 
ments  (data,  voice,  video),  computer  network  support,  and  antijam  requirements.  Identify  unique  intelli¬ 
gence  information  requirements,  including  intelligence  interfaces,  communications,  and  data  base  support 
that  pertain  to  target  and  mission  planning  activities,  threat  data,  etc.  ^Reference  the  system’s  intelligence 
support  requirements  in  the  ISP  as  a  complement  to  operational  requirements  in  the  ORD  (see  AFIs  14- 
208  and  AFI 33-102).  Describe  the  electromagnetic  spectrum  resources  required  by  the  system  (e.g.,  gen¬ 
eral  location  in  the  spectrum,  bandwidth  required). 

b.  Transportation  and  Basing.  Describe  how  the  system  will  be  moved  either  to  or  within  the  theater. 
Identify  any  lift  constraints.  Detail  the  basing  and  associated  facilities  available  for  training  locations  and 
main  and  forward  operating  bases. 

c.  Standardization,  Interoperability,  and  Commonality.  Describe  considerations  for  joint  use,  NATO 
cross-servicing,  etc.  Identify  procedural  and  technical  interfaces  as  well  as  communications,  protocols, 
and  standards  required  to  be  incorporated  to  ensure  interoperability  with  other  Service,  joint  Service,  and 
Allied  systems.  Address  energy  standardization  and  efficiency  needs  for  both  fuels  and  electrical  power, 
as  applicable.  *Address  system  power  conversion  and  surge  protection  requirements  envisioned  for  the 
operating  environment. 

d.  Mapping,  Charting,  and  Geodesy  Support.  Identify  cartographic  materials,  digital  topographic  data, 
and  geodetic  data  needed  for  system  employment.  Where  possible.  Defense  Mapping  Agency  (DMA) 
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standard  military  data  will  be  used.  *NOTE:  Use  current  World  Geodetic  System  Datums  (i.e.,  WGS 
84).  For  waiver  approval,  contact  HQ  USAF/IN. 

e.  Environmental  Support.  Identify  the  standard  and  unique  weather,  oceanographic,  and  astrogeophys- 
ical  support  required.  Include  data  accuracy  and  forecast  requirements. 

7.  Force  Structure.  Estimate  the  number  of  systems  or  subsystems  needed,  including  spares  and  training 
units.  Identify  the  platforms  and  quantities  of  these  platforms  (including  other  Services’  or  Government 
agencies’,  if  appropriate)  that  will  employ  the  systems  or  subsystems  being  developed  and  procured  to  sat¬ 
isfy  this  ORD.  *  Force  structure  estimate  will  include  numbers  of  systems  sufficient  for  gained  reserve 
component  (Air  National  Guard  and  Air  Force  Reserve)  forces  under  AFI 10-301. 

8.  Schedule  Considerations.  Define  what  actions,  when  complete,  will  constitute  attainment  of  IOC  and 
FOC  (provide  flexibility  for  these  to  be  revised  as  the  program  is  progressively  defined  and  tradeoff  stud¬ 
ies  are  completed).  Clearly  specify  the  operational  capability  or  level  of  performance  necessary  to  declare 
IOC  and  FOC.  Include  the  number  of  operational  systems,  operational  and  support  personnel,  facilities, 
and  organizational,  intermediate,  and  depot  support  elements  that  must  be  in  place.  If  availability  in  a 
specific  timeframe  is  important,  specify  an  objective  for  IOC  declaration.  Describe  the  impact  if  this 
objective  is  not  -achieved  and  identify  a  window  of  acceptability,  if  appropriate.  *The  required  actions 
and  desired  dates  to  attain  IOC  should  include  RAA  date,  projected  trial  period,  required  organic  support 
capability  dates,  etc.  The  actual  IOC  declaration  should  be  viewed  as  an  event  rather  than  a  calendar  date 
(paragraph  7,  basic  text). 
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Attachment  8 


ORD  REQUIREMENTS  CORRELATION  MATRIX  (RCM) 

(PROCEDURES  AND  FORMAT) 

Section  ASA — RCM  Procedures 

A8.1.  The  Requirements  Correlation  Matrix  (RCM)  is  a  mandatory  attachment  to  all  Air  Force  ORDs. 
The  operating  command  is  responsible  for  preparing  the  RCM.  NOTE:  It  is  critical  that  the  definitions 
listed  in  attachment  7  (ORD  Procedures),  paragraph  A7.1.1  be  thoroughly  reviewed  before  devel¬ 
oping  the  RCM. 

A8.2.  The  purpose  of  the  RCM  is: 

•  To  provide  Air  Force  senior  leadership  a  summary  of  the  user's  operational  requirements  and  the 
supporting  rationale. 

•  To  document  the  evolution  of  the  user's  operational  requirements  as  the  system  matures  and  the 
rationale  for  any  changes. 

•  To  provide  a  tool  to  identify  user-nominated  key  performance  parameters  for  inclusion  in  the  per¬ 
formance  section  of  the  Acquisition  Program  Baseline  (APB).  The  RCM  contains  system  opera¬ 
tional  characteristics  and  capabilities  quantified  by  thresholds,  as  appropriate,  and  desired 
objectives  as  defined  in  the  ORD. 

RCMs  are  not  to  be  used  or  viewed  as  stand-alone  documents.  The  operational  characteristics  and 
capabilities  contained  in  the  RCM  serve  as  the  foundation  for  developing  the  System  Maturity  Matrix 
(SMM)  by  the  implementing  command  and  the  APB. 

A8.3.  The  RCM  is  a  three-part  attachment  that  consists  of  a  Requirements  Correlation  Matrix,  Part  I;  a 
Supporting  Rationale  for  System  Characteristics  and  Capabilities  Sheet,  Part  II;  and  a  Rationale  and 
Needs/Requirements  Change  Sheet,  Part  III. 

A8.3.1.  RCM  Part  I,  Requirements  Correlation  Matrix  (figure  A8.1).  The  RCM  Part  I  will 
include: 

•  A  tabular  summary  of  the  operational  requirements  included  in  paragraph  4  of  the  ORD  text  (i.e., 
the  capabilities  and  characteristics  for  system  performance,  logistics  and  readiness,  and  critical  sys¬ 
tem  characteristics,  with  their  associated  thresholds  and  objectives). 

•  Other  quantifiable,  operationally  significant,  requirements  (not  specifications)  from  elsewhere  in 
the  ORD  that  help  define  the  system,  as  deemed  appropriate  by  the  user. 

•  All  key  performance  parameters  recommended  by  the  user  for  inclusion  in  the  performance  section 
of  the  APB.  The  characteristics  and  capabilities  listed  in  the  RCM  for  ORD  I  will  likely  be  few  in 
number. 

As  the  system  matures  and  becomes  better  defined,  sub-elements  or  new  characteristics  and  capabili¬ 
ties  may  be  added.  While  new  items  add  better  definition,  they  may  also  limit  the  program  director's 
flexibility.  A  threshold  is  a  minimum  acceptable  operational  value  for  a  system  capability  or  charac¬ 
teristic  which,  in  the  user's  judgment,  is  necessary  to  provide  an  operational  capability  that  will  satisfy 
the  mission  need  (DoD  Instruction  5000.2/Air  Force  Supplement  1).  An  objective  is  a  value  beyond 
the  threshold  that  could  potentially  have  a  measurable,  beneficial  impact  on  capability  or  operations 
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and  support  above  that  provided  by  the  threshold  value  (e.g.,  additional  range  that  might  reduce  the 
number  of  refueling  systems  required)  (DoD  Instruction  5000.2/ Air  Force  Supplement  1).  A  defini¬ 
tion  of  each  column  follows: 

A8.3.1.1.  System  Capabilities  and  Characteristics  Column.  List  the  system’s  general  opera¬ 
tional  characteristics  and  capabilities  outlined  in  the  ORD,  consistent  with  paragraph  A8.3.1,  that 
are  realistic,  meaningful,  and  germane  to  the  mission  need,  including  mission  planning  require¬ 
ments.  Adjacent  to  each  capability  and  characteristic,  reference  the  paragraph  in  the  ORD  text 
from  which  it  came.  Characteristics  and  capabilities  will  vary  depending  on  the  type  of  system 
being  described;  they  should  generally  include,  but  are  not  limited  to,  areas  such  as  speed,  range, 
accuracy,  payload,  probability  of  kill,  capacity,  survivability,  reliability  and  maintainability,  mis¬ 
sion  capable  rates,  frequency  and  duration  of  preventative  or  scheduled  maintenance  action,  oper¬ 
ational  effectiveness,  and  suitability.  They  should  be  necessary  for  successful  operational  mission 
accomplishment. 

A8.3.1.2.  Thresholds  and  Objectives  Columns  Supporting  Milestones  I  Through  IV. 

Include  the  threshold  and  objective  values  for  each  of  the  characteristics  and  capabilities  listed  in 
the  System  Capabilities  and  Characteristics  Column.  As  the  program  matures  and  needs  evolve 
into  firm  thresholds  and  objectives  (vice  TBDs),  these  columns  will  reflect  system-specific  perfor¬ 
mance  and  support  values  agreed  to  by  the  using,  implementing,  and  supporting  commands. 
These  thresholds  and  objectives  normally  will  form  the  basis  for  contractual  specifications.  The 
value  for  each  threshold  must  be  referenced  in  Part  II,  describing  its  relationship  to  mission  suc¬ 
cess  and  how  that  value  was  derived.  When  a  threshold  or  objective  changes  from  an  earlier  ORD 
iteration,  explain  and  give  the  rationale  for  the  change  in  Part  III  of  the  RCM. 

A8.3.1.3.  Key  Performance  Parameters.  Any  characteristic  or  capability  with  an  associated 
threshold  is  a  candidate  for  a  key  parameter  and  inclusion  in  the  APB.  The  operating  command 
should  recommend  key  performance  parameters  for  inclusion  in  the  APB  by  marking  the  specific 
capability  and  (or)  characteristic  with  an  asterisk  (*)  as  indicated  in  figure  A8.1.  Key  perfor¬ 
mance  parameters  must  have  threshold  and  objective  values  (objectives  may  be  the  same  as  the 
thresholds  when  an  operationally  significant  increment  above  the  threshold  is  not  identifiable  or 
useful).  NOTE:  According  to  DoD  5000  series  directives,  the  Milestone  Decision  Authority 
approves  the  APB  and  may,  therefore,  add  additional  key  parameters  to  the  APB  during  the  mile¬ 
stone  decision  process. 

A8.3.2.  RCM  Part  II,  Supporting  Rationale  for  System  Characteristics  and  Capa  bilities 
Sheet  (figure  A8.2).  Cite  specific  studies,  analyses,  threat  assessments,  modeling,  or  other  reference 
sources  (including  informed  military  judgments)  that  justify  and  substantiate  thresholds  for  each  sys¬ 
tem  characteristic  or  capability. 

A8.3.3.  RCM  Part  III,  Rationale  and  Needs/Requirements  Change  Sheet  (figure  A8.3).  Show 
the  rationale  for  changes  in  system  characteristics,  performance,  and  supporting  parameters,  etc.  As 
appropriate,  cite  the  report  title,  document  number,  supporting  analysis,  get-well  date,  and  schedules, 
etc.  (Example  shows  the  evolutionary  process  of  refining  characteristics  and  capabilities.) 

Section  A8B — RCM  Format 

A8.4.  The  following  paragraphs  illustrate  the  RCM  format. 
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(EXAMPLE) 

RCM  PART  I: 

Figure  A8.1.  RCM  Part  I  Format. 


REQUIREMENTS  CORRELATION  MATRIX 


PARTI 


SYSTEM  CAPABILITIES 

AND  CHARACTERISTICS 

ORD  I 

1 

ORD  II 

ORD  III 

Thresholds 

Objectives 

Thresholds 

Objectives 

Thresholds 

Objectives 

1.  Non- Afterburner 

Supersonic  Cruise  (4. a. (I)) 

a.  Sustained  Speed  * 

L50M 

L50M 

1.7M 

2.0M 

1.5M 

2.0M 

b.  Dash 

TBD 

>1.5M 

2.1M 

2.4M 

2.1M 

2.4M 

2.  Radar  Search  and  Track  (4.a.(2)) 

a.  Search  (No.  of  Targets)  * 

6 

12 

6 

16 

6 

16 

b.  Track  (No.  of  Targets) 

TBD 

6 

4 

8 

4 

8 

c  Search  Range  (NM)  * 

100 

250 

150 

200 

150 

200 

d  Track  Range  (NM) 

TBD 

125 

50 

100 

50 

100 

3.  Weapons  Compatibility  (4a.(2)) 

a.  Air-to-surface  (Load) 

CBU-87,  89  (4) 

CBU-97  (4) 

CBU-87,  89  (4) 

CBU-97  (4) 

CBU-87,  89  (4) 

CBU-97  (4) 

AGM-137  (2) 

MK  62  Mine  (6) 

AGM-137  (2) 

MK  62  Mine  (6) 

AGM-137  (2) 

MK  62  Mine  (6) 

JDAM  I  (2) 

JDAM  111  (2) 

JDAM  I  (2) 

JDAM  III  (2) 

JDAM  I  (2) 

JDAM  III  (2) 

AGM-88  (4) 

AGM-88  (4) 

AGM-88  (4) 

b.  Air-to-air  (Load)  * 

AIM- 120  (4) 

AIM- 120  (4) 

AIM- 120  (4) 

AIM-9M  (4) 

AIM-9M  (4) 

A1M-9M  (4) 

4.  Terrain  Following  (TF) 

Min  Altitude  (Ft)  (4.a.(3))  * 

100  ALL  WX 

100  ALL  WX 

100  ALL  WX 

100  ALLWX 

200  ALLWX 

100  ALL  WX 

5.  Operational  Availability  (4.b.(l)) 

85% 

90% 

21  Hrs/day 

22  Hrs/day 

21  Hrs/day 

22  Hrs/day 

6.  BIT  False  Alarm  Rate  (4.b.(2)) 

10% 

5% 

10% 

1  % 

10% 

1  % 

7.  Radar  Cross  Section  (m2)  (4.c.(l))  * 

3 

1 

3 

1 

3 

1 

*  =  Key  Performance  Parameter 

As  of  Date::  4.Tulvl9XX 


Notes: 

1.  Place  an  asterick  (*)  adjacent  to  each  specific  capability  or  characteristic  the  user  wishes  to  be  a 
key  performance  parameter  to  be  placed,  along  with  its  associated  threshold  and  objective,  in  the 
performance  section  of  the  APB. 

2.  Adjacent  to  each  capability  and  characteristic  listed  in  the  RCM,  reference  the  appropriate  ORD 
paragraph  from  which  it  came. 

3.  Avoid  the  use  of  “YES”  thresholds;  instead  depict  the  requirement  as  shown  in  the  weapons  com- 
patiblility  example. 


RCM  PART  II: 

Figure  A8.2.  RCM  Part  II  Format. 


(EXAMPLE) 
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^  * 


REQUIREMENTS  CORRELATION  MATRIX 
Part  11 

(Supporting  Rationale  for  System  Characteristics  and  Capabilities) 


AS  OF  DATE:  4Jull9XX 

Parameter  l~Non- Afterburner  Supersonic  Cruise.  Tactical  Fighter  Weapon  Center  Study  7X-XXX, 
15  Jan  XX,  concluded  new  fighter  must  have  capability  to  engage  targets  at  supersonic  speeds  after  flying 
over  enemy  territory  for  XXXX  miles.  Consequently,  aircraft  must  have  supersonic  cruise  without  resort¬ 
ing  to  high  fuel  consuming  afterburners. 

Parameter  2-Radar  (Fire  and  Forget  Capable).  DIA  Report  #XX-123-X-90  (S/NF)  states  that  in  the 
next  15  years  potential  adversaries  will  own  more  third-generation  Former  Soviet  Union  (FSU)  fighters 
than  the  number  of  fighters  operated  by  the  United  States.  To  mitigate  the  numbers  difference  during  an 
engagement,  the  F-YY  must  be  able  to  launch  multiple  missiles  and  immediately  begin  maneuvering.  It 
will  not  be  able  to  provide  missile  guidance  signals.  Therefore,  the  F-YY  must  be  designed  to  accept  air- 
to-air  missiles  that  independently  track  their  targets  after  release. 

Parameter  3— Weapons  Compatibility.  The  Air  Combat  Command  (ACC)  Study  "Future  Look 
Fighter,"  dated  15  Aug  XX,  identifies  next  generation  fighter  standard  air-to-surface  and  air-to-air  muni¬ 
tions  compatibility  and  loads  (excluding  MK  series  munitions)  consistent  with  the  specified  threshold 
requirements. 

Parameter  4— Terrain  Avoidance  (TA)/Terrain  Following  (TF).  The  Air  Combat  Command  (ACC) 
Study  "Future  Look  Fighter,"  dated  15  Aug  XX,  states  next  generation  fighter  must  be  capable  of  pene¬ 
trating  enemy  airspace  in  weather  conditions  expected  XX%  of  the  time,  at  altitudes  no  higher  than  200 
AGL.  The  high  combat  workload  in  a  single-seat  aircraft  mandates  an  automatic  TF  system. 

Parameter  5— Operational  Availability.  Operational  availability  values  are  based  on  projected  wartime 
sortie  requirements  as  documented  in  OPLAN  XXX. 

Parameter  6— BIT  False  Alarm  Rate.  AFPD  10-XX  establishes  BIT  false  alarm  rates  for  next  genera¬ 
tion  aircraft  will  not  exceed  10  percent. 

Parameter  7— Radar  Cross  Section.  DIA  Report  #XX-123-X-90  (S/NF)  predicts  the  probability  of 
potential  adversaries  next  generation  fighter  air-to-air  radar  capability  and  future  surface-to-air  tracking 
radar  capability  to  track  a  3m2  target  inside  lethal  missile  launch  range  to  be  less  than  10  percent.  The 
probability  of  the  adversaries’  to  detect  and  track  a  lm2  target  inside  lethal  missile  range  is  predicted  to  be 
virtually  nil. 

RCM  PART  III: 

Figure  A8.3.  RCM  Part  III  Format. 

(EXAMPLE) 

REQUIREMENTS  CORRELATION  MATRIX 
Part  III 

(Rationale  &  Needs/Requirements  Changes) 


79 


AS  OF  DATE: 

Parameter  la.  Sustained  non-afterburner  supersonic  cruise  speed  (M)  reduced  from  1 .7M  to  1 .5M. 
Reduction  due  to  cost-performance  tradeoff  conducted  by  contractor  at  direction  of  program  office  on  9 
Apr  XX.  Accepted  by  HQ  ACC  as  final  threshold  on  14  May  XX. 

Parameter  3a.  AGM-88  HARM  weapons  compatibility  moved  from  objective  to  threshold  for  this  Mile¬ 
stone  III  ORD  due  to  the  addition  of  lethal  suppression  of  enemy  air  defenses  as  a  primary  mission  for  the 
F-YY. 

Parameter  4.  Automatic  terrain  following  (ATF)  contour  threshold  raised  from  100  feet  AGL  to  200  feet 
AGL  in  weather  (WX)  conditions  expected  XX%  of  the  time.  Increase  is  result  of  technical  problems  in 
ATF  radar  processor.  The  error  rate  for  climb  commands  (clutter  problems)  is  unacceptable  at  100  feet, 
and  there  is  no  known,  cost-effective  technical  fix.  Change  proposed  by  contractor  on  6  Feb  XX  and 
accepted  by  HQ  ACC  on  15  Apr  XX.  Program  office  revised  contract  specifications  on  20  May  XX. 
Identified  as  a  Key  Performance  Parameter  in  this  Milestone  III  ORD  to  indicate  that  any  additional 
increase  in  ATF  contour  is  unacceptable  to  the  user.  Addition  of  this  key  performance  parameter  vali¬ 
dated  by  the  Joint  Requirements  Oversight  Council  (JROC).  Operational  impact  is  negligible  because  of 
smaller  than  expected  front  aspect  radar  cross  section. 
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